\chapter{Part C -- Seting up the Wiki server}

The interface of a Wiki server is given by:

\begin{enumerate}
\item Issuing a GET request to \url{http://foo.daimi.au.dk:xyz/Wiki/Server} will result in an XML document listing all Wiki pages stored on that server, identified by their Wiki words. 
\item Issuing a GET request to \url{http://foo.daimi.au.dk:xyz/Wiki/Server?word=bar} will result in the WikiXML document corresponding to the word bar. 
\item Issuing a DELETE request to \url{http://foo.daimi.au.dk:xyz/Wiki/Server?word=bar} will delete the WikiXML document corresponding to the word bar. 
\item Issuing a PUT request to \url{http://foo.daimi.au.dk:xyz/Wiki/Server?word=bar} with a request body containing a WikiXML document will store this document as the one associated with the word bar on the given server.
\end{enumerate}

Our solution consists of a deployment description \path{WEB-INF/web.xml}, a library with jar files \path{WEB-INF/lib}, a library with class files \path{WEB-INF/classes} and a library with XML documents \texttt{WEB-INF/documents}. It will be installed on a Tomcat server at the Daimi network. We are to describe our implementation, covering such issues as synchronization, validation, and fault tolerance.

We will use the \texttt{JDOM} package to navigate through the XML documents. We define a class \texttt{Server} as an extension of \texttt{HttpServlet} from the \texttt{servlet-api} package. We will use the \texttt{net.sf.saxon} package to validate XML documents against XML schemas and transforming them with XML stylesheets. The packages will be placed in the \path{WEB-INF/lib} library which will automatically be loaded by Tomcat. In \texttt{web.xml} we simply specify the mapping of \texttt{/Server} to the \texttt{Server} class. Thus \texttt{GET}, \texttt{PUT} and \texttt{DELETE} requests call the \texttt{doGet}, \texttt{doPut} and \texttt{doDelete} method in this class. 

\section{GET}

It is now simple to implement the first requirement of the server interface. We set the Content-Type of the response to 'text/xml' and initiates a writer for the body of the response. The listing of the documents on the server is given in a document \texttt{WEB-INF/documents/listing.xml}. We create a file with the abstract path \texttt{webapps/Wiki/WEB-INF/documents/listing.xml} and lets an instance of \texttt{SAXBuilder} build a document of this file. We then let an \texttt{XMLOutputter} output this document through the writer. If something went wrong creating the document and writing it to the response any exceptions are caught and reported to the client through a \texttt{ServletException} holding the exception message. 

The listing document is created by an external class \texttt{CreateListing}. This class uses \texttt{File}'s method \texttt{list(Filter)} to create a list of the path names of the XML documents in \texttt{WEB-INF/documents} by specifying in an implementation of the interface \texttt{Filter} that we only accept path names ending with \texttt{.xml} that different from \texttt{listing.xml}. We create a root element \texttt{wiki} and for each path name we build the corresponding document, extract the value of the \texttt{name} attribute and add a \texttt{word} element containing the name to the \texttt{wiki} element. We then output the document consisting of the \texttt{wiki} root element.

The \texttt{GET} request with a parameter is a simple extension of this implementation. We start by getting the parameter \texttt{word} of the request header. We now test if we actually get a result, if not we return the \texttt{listing.xml} document as described above. Else we proceeds as before creating a document corresponding to the path \texttt{webapps/Wiki/WEB-INF/documents/word.xml} and write it to the response body. If no document excists with the given name the client is notified with an exception.

\section{PUT}

The \texttt{PUT} request is a bit more complicated. We have to make sure the document to be put is valid WikiXML and that no race conditions occur storing the document in the database. We will first retrieve the document to be put from the body. To do this we get a reader for the body and creates an instance \texttt{b} of \texttt{SAXBuilder}. We set the \texttt{setValidation} of \texttt{b} to true and specify which schema to validate against with the two calls \texttt{b.setProperty} ("\url{http://java.sun.com/xml/jaxp/properties/schemaLanguage}", "\url{http://www.w3.org/2001/XMLSchema}");   \texttt{b.setProperty} ( "\url{http://java.sun.com/xml/jaxp/properties/schemaSource}",  " \url{webapps/Wiki/WEB-INF/source/WikiXML.xsd}");. Now when we build the document of the body it is automatically validated against the schema. If it is not valid an exception is thrown to the client. 

We retrieve the \texttt{word} parameter of the header and have now come to writing the document to the database. Since we cannot allow two clients to write to the same file in the database we have to synchronize the filewriting. Optimally we would synchronize filewriting to the specific file, but we will simply synchronize the filewriting process in itself. We do this by extracting the filewriting process from the \texttt{doPut} method to a self-contained method with the tag \texttt{synchronized}. Thus whenever the \texttt{Server} object is filewriting it is locked from any interaction. This is a simple and very rough way to prevent race-conditions but in this context it will do. We have minimized the time the server is locked and the filewriting process shouldn't take long. 

\section{DELETE}

The \texttt{DELETE} request is pretty simple to implement. We simply retrieve the \texttt{word} parameter of the header, create a file with the abstract path \path{webapps/Wiki/WEB-INF/documents/word.xml} and tries to delete it with the \texttt{delete} method of the file. If the the file corresponding to the requested document doesn't excist or it is not possible to delete an exception is thrown to the client. We have extracted the filedeletion from the \texttt{toDelete} method and synchronized the process as before. We have done this because any database maintainance should be resistant to race-conditions, though no race-conditions really are harmful to this operation.

\section{Registering our Wiki server in the Wiki metaserver}

Our server is now fully functional and we are ready to register it in the Wiki metaserver using the form from \url{http://www.daimi.au.dk/dWebTek/WikiRegister.html}. The Tomcat server is installed at the machine \texttt{camel26} at the Daimi network on port \texttt{8128}. 